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Introduction 


Purpose.  This  paper  presents  observations,  findings,  and  conclusions  concerning  the 
impact  of  information  technologies  on  future  battle  command.  This  work  supports  the 
experimental  work  of  the  Battle  Command  Battle  Laboratory  -  Fort  Leavenworth  (BCBL(L)). 

Focus.  The  Training  and  Doctrine  Command  (TRADOC)  Analysis  Center  (TRAC) 
addressed  information  technology  issues  as  part  of  the  overall  analytical  support  to  the  Fiscal 
Year  (FY)  95  Mobile  Strike  Force  Battle  Command  (MSF/BC  95)  Experiment,  a  subordinate 
study  of  the  Prairie  Warrior/Mobile  Strike  Force  1995  Advanced  Warfighting  Experiment 
(PW/MSF  95  AWE).  The  Mobile  Strike  Force  (MSF)  is  a  notional,  division-sized  force  used  by 
the  Army  to  investigate  Force  XXI  issues,  to  support  building  the  future  force.  The  relevant 
objective,  issues,  and  essential  elements  of  analysis  (EEA)  addressed  in  this  investigation  are 
shown  below. 


BCBL(L)  Experimentation  Objective 

Explore  requirements  for  information  technologies  to  provide  the  command  and  staff  team  an  adequate  relevant 
common  picture. 

Relevant  Study  Issues 

•  How  will  battle  command  information  technology  capabilities  (digitization)  collectively  affect  division  staff 
processes  and  organization? 

•  Does  computer-assisted  wargaming  enhance  integration  of  fire  support  and  maneuver? 

•  Do  fully  integrated  command,  control,  and  intelligence  systems  better  achieve  a  relevant  conunon  picture  of 
the  battlefield  than  "stove-piped"  systems? 

EEAs 

•  In  addition  to  effects  on  situation  assessment,  what  are  the  perceived  contributions  and  challenges  of  the 
individual  information  technologies? 

•  What  are  the  observed  and  perceived  effects  of  computer-assisted  wargaming  on  mission  planning? 

•  In  addition  to  the  observed  effects  of  the  suite  of  information  technologies,  what  are  the  perceived 
contributions  of  these  collective,  integrated  capabilities? 


Approach 

Experiment  Context 

The  BCBL(L)  sought  to  emulate  the  knowledge-based  environment  envisioned  as  that 
relevant  to  Force  XXI.  The  Command  and  General  Staff  Officer  Course  (CGSOC)  Battle 
Command  Elective  (BCE)  was  used  as  the  vehicle  for  experimentation.  The  BCE  was  developed 
jointly  by  BCBL(L)  and  CGSC.  This  course  was  jointly  taught  by  instructors  fi'om  the  U.S.  Army 
Command  and  General  Staff  College  (CGSC),  and  the  Army  Research  Institute  (ARI)  -  Fort 
Leavenworth  Field  Unit.  There  were  73  CGSOC  students  in  the  1995  BCE  who  were  assigned  to 
the  command  and  staff  of  the  MSF.  An  active  duty  general  officer  commanded  the  MSF. 

The  BCE  students  were  trained  through  a  holistic  approach  including  classroom 
instruction,  hands-on  system  training,  one-on-one  leader  development  sessions,  and  tactics, 
techniques,  and  procedures  (TTP)  development  sessions.  Further,  there  were  three  simulation 
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exercises  (SIMEXes)  leading  up  to  the  culminating  CGSOC  exercise,  Prairie  Warrior  (PW).  The 
exercises  were  conducted  using  the  Corps  Battle  Simulation  (CBS)  as  the  exercise  driver.  The 
information  technologies  were  used  throughout  the  SIMEXes,  as  an  integral  part  of  MSF 
operations. 

The  BCE  students  were  required  to  use  these  technologies  in  this  environment  while 
learning  the  MSF  concept,  as  well  as  a  concept  for  division  staff  organization  and  process  -  the 
Digitized  Battle  Staff  (DBS).  This  provided  the  MSF  Commander  quite  a  challenge,  in  addition 
to  that  faced  by  the  students  as  the  operators  in  this  environment.  Besides  these  two  main 
concepts,  the  BCE  students  were  also  exposed  to  various  aspects  of  the  information  operations 
(10)  concept  throughout  the  course  of  the  experiment.  Although  the  analytic  participants  in  the 
experiment  had  sought  to  control  the  number  of  variables,  the  introduction  of  multiple  concepts 
occurred  and  was  recognized  by  the  MSF  Commander  as  problematic. 

Analytic  Methodology 

The  analytic  methodology  focused  on  the  data  collection  effort.  There  were  several 
sources  for  data  to  answer  the  aforementioned  EEAs.  These  were  historical  information,  direct 
observation  of  the  BCE  during  all  the  activities  previously  cited,  and  student  surveys  administered 
during  the  experiment.  Direct  observation  was  enhanced  by  help  from  the  Operational  Test  and 
Evaluation  Command  (OPTEC),  which  augmented  the  TRAC  study  team  during  the  SIMEXes 
and  PW.  These  observations  were  the  principal  means  to  evaluate  the  technologies  and  to 
develop  further  requirements  for  the  future  battle  command  system.  The  information  collected 
was  used  to  compare  the  information  technologies,  both  to  each  other,  and  to  other  government 
and  commercially  available  systems.  There  was  no  readily  observable  baseline  information 
technology  system  for  comparison. 

A  survey  assessed  the  technological  literacy  of  the  BCE  students.  The  results  of  this 
survey  provided  insight  into  why  and  how  the  students  operated  in  the  environment  as  they  did, 
and  identified  further  challenges  regarding  information  technologies.  A  survey  also  addressed  the 
importance  and  difficulty  of  acquisition  of  the  acknowledged  leader  competencies.  Included 
among  them  is  the  use  of  available  systems,  which  directly  relates  to  the  assessment  of  the 
information  technologies.  A  third  survey  addressed  the  individual  and  collective  effects  of  the 
suite  of  systems  providing  situational  awareness  to  the  MSF,  and  the  contribution  of 
computer-assisted  war-gaming. 

Experiment  Information  Technology  Systems 

The  systems  discussed  in  this  section  are  categorized  as  either  protoype  or  actual  battle 
command  support  systems,  and  training  simulation  support  systems. 

Battle  Command  Systems 

Phoenix.  The  Phoenix  system  was  a  developmental  software  package  used  as  the  MSF 
battle  command  decision  support  system  (BCDSS).  The  Phoenix  software  package  ran  on  a 
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SUN  SPARC  20  workstation  under  the  UNIX  operating  system.  Phoenix  required  a  local  area 
network  (LAN)  and  associated  software  to  complete  the  required  workstation  connectivity  and 
DBS  architecture.  Phoenix  was  essentially  a  surrogate  for  an  upgraded  Maneuver  Control  System 
(MCS).  Software  development  continued  throughout  the  experiment.  The  varied  changes  which 
occurred,  although  enhancements  for  the  most  part,  were  the  source  of  much  disruption  to  the 
student  training,  and  to  MSF  planning  and  execution  during  the  experiment.  Phoenix  was 
operated  by  the  BCE  students.  The  salient  capabilities  and  characteristics  are  shown  in  the  box. 

*  digital  mapping 

*  graphics  package  to  develop  operations  overlays 

*  database  management  system  to  handle  large  databases  containing  all  the  force  level  information 

*  electronic  mail  to  allow  work  stations  to  inter-communicate 

*  videoteleconferencing  (VTC)  to  allow  virtual  collocation  between  staff  cells 

*  collaborative  graphics  package  (whiteboard)  to  permit  digital  interactive  collaboration 

*  word  processing 


ASAS  Warrior.  The  All  Source  Analysis  System  (ASAS)  Warrior  workstation  was 
provided  to  the  intelligence  processing  section  of  the  MSF  staff  to  perform  the  intelligence 
collection  and  analysis  functions.  ASAS  Warrior  provided  via  LAN  to  Phoenix  the  location  and 
status  of  all  enemy  forces  identified  through  the  intelligence  cycle.  The  ASAS  Warrior  software 
also  ran  on  a  SUN  SPARC  20  workstation  under  UNIX  and  required  a  LAN  and  associated 
software  for  workstation  connectivity.  This  system  required  dedicated  system  operators  who 
came  from  the  Intelligence  School  to  support  the  experiment.  This  system  provided  the 
capabilities  shown  in  the  box. 
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*  basic  map  background 

*  database  management  system  to  collate,  sort  and  analyze  intelligence  data 

*  graphics  package  to  permit  the  construction  of  control  measure  graphics  overlays  for  the  map 
background 

*  electronic  mail/file  transfer  routine  to  permit  the  transmission  of  inteUigence  databases  to  other 
elements 

AFATDS.  The  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  was  provided 
to  the  field  artillery  elements  of  the  MSF  staff  to  perform  fire  support  planning,  control,  and 
execution  functions.  AFATDS  software  also  ran  on  a  SUN  SPARC  20  workstation  under  UNIX 
or  a  MILTOPE  computer.  AFATDS  required  a  LAN  and  associated  software  for  workstation 
coimectivity.  This  system  required  dedicated  system  operators  who  came  from  the  Field  Artillery 
School  to  support  the  experiment  This  system  provided  the  capabilities  shown  in  the  box  below, 
basic  map  background 

’  graphics  package  to  permit  the  creation  of  control  measure  graphics  overlays  for  the  map 
database  management  system  to  provide  the  capability  to  receive,  sort,  collate,  and  prioritize 
target  information,  and  to  transmit  that  information  to  firing  units  in  the  form  of  fire  missions 
*  electronic  mail/file  transfer  routine  to  permit  the  receipt  and  transmission  of  target  information 

FAADC2I.  The  Forward  Area  Air  Defense  Command,  Control,  and  Intelligence 
(FAADC2I)  system  was  provided  to  the  air  defense  elements  of  the  MSF  staff  to  perform 
planning,  coordination,  and  execution  functions  of  air  defense  fires  available  to  the  MSF.  The 
FAADC2I  software  also  ran  on  a  SUN  SPARC  20  workstation  under  UNIX  or  a  MILTOPE 


computer  and  required  a  LAN  and  associated  software  for  workstation  connectivity.  This  system 
required  dedicated  system  operators  who  came  from  the  Air  Defense  School  to  support  the 
experiment.  This  system  provided  the  capabilities  shown  in  the  box. _ 

♦  basic  map  background 

♦  graphics  package  to  permit  the  creation  of  control  measure  graphics  overlays  on  the  map 

♦  database  management  system  to  provide  the  capability  to  receive,  sort,  collate  and  prioritize  air 
defense  target  information  and  to  transmit  that  information  to  firing  units 

♦  electronic  mail/file  transfer  routine  to  permit  the  receipt  and  transmission  of  target  information 


LAD.  The  Logistics  Anchor  Desk  (LAD)  was  provided  to  the  logistics  elements  of  the 
MSF  staff  to  perform  planning,  coordination,  and  execution  functions  associated  with  logistical 
operations  in  support  of  the  MSF.  LAD  software  also  ran  on  a  SUN  SPARC  20  workstation 
under  UNIX  and  required  a  LAN  and  associated  software  for  workstation  connectivity.  This 
system  required  dedicated  system  operators  who  came  from  the  Logistics  Center  to  support  the 
experiment.  This  system  provided  the  capabilities  shown  in  the  box. _ 

♦  basic  map  background 

♦  graphics  package  to  permit  the  creation  of  control  measure  graphics  map  overlays 

♦  database  management  system  to  provide  the  capability  to  receive,  sort,  collate,  account  for  and  prioritize 

logistics  information,  and  to  transmit  that  information  to  logistics  units 

♦  electronic  mail/file  transfer  routine  to  perimt  the  receipt  and  transmission  of  logistics  information 

♦  limited  modeling  to  perimt  the  examination  of  various  logistics  support  scenarios 


TEM/OPS.  The  Engineer  School  provided  the  Terrain  Evaluation  Model/Obstacle 
Planmng  System  (TEM/OPS)  to  the  MSF  engineer  and  all  brigade  headquarters  to  perform 
detailed  terrain  analysis  and  to  support  engineer  planning,  coordination  and  execution.  The 
TEM/OPS  software  ran  on  a  UNIX  based  SUN  SPARC  20  workstation  and  required  a  LAN  and 
associated  software  for  workstation  connectivity.  System  operators  from  the  Topographic 
Engineering  Center  supported  the  experiment,  although  BCE  students  also  operated  the  system. 
The  TEM/OPS  system  provided  the  following  capabilities: _ 

♦  high  quality  digital  mapping  and  geographic  information  system  that  permitted  the  conduct  of 
detailed,  multi-faceted,  terrain  analysis 

♦  graphics  package  that  permitted  the  creation  of  control  measure  graphics  and  obstacle  planning 
overlays  for  the  terrain  displays 

♦  electronic  mail/file  transfer  routine  that  permitted  the  receipt  and  transmission  of  terrain  and 
graphics  information 

♦  planning  tool  that  permits  the  comparison  of  engineer  resource  requirements  with  capabilities, 

conducting  resource  allocation  and  prioritization  of  work  efibrt,  generating  logistics  resource 
requirements _ 


NET.  The  Network  Evaluation  Tool  (NET)  was  provided  to  the  signal  section  of  the 
MSF  staff  to  perform  communications  network  planning  and  network  analysis.  The  NET 
software  ran  on  a  DOS-based  personal  computer  (PC)  as  a  stand-alone  system.  The  two  BCE 
signal  officer  branch  students  were  trained  by  the  Signal  School  to  use  the  system.  The  NET 
provided  the  following  capabilities: 
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♦  digital  map  background 

♦  graphics  package  that  permits  the  creation  of  control  measure  graphics  overlays  for 
the  map 

♦  communications  network  assessment  tool  that  permits  the  evaluation  of 
communications  node  connectivity  based  upon  terrain  location  and  masking, 
communications  network  loading,  communications  network  connectivity  and  routing 


OPLOG  Planner.  The  Operations  Logistics  (OPLOG)  Planner  was  provided  to  the 
logistics  elements  of  the  MSP  staff  to  perform  logistical  planning,  coordination  and  execution 
functions.  The  OPLOG  planner  provided  the  capability  to  create  detailed  force  organizations  and 
structures  and  to  develop  detailed  logistics  resource  requirements  for  various  operational 
scenarios.  This  software  program  ran  on  a  DOS-based  PC.  CGSC  logistics  instructors  trained 
student  users. 

LPXMED.  The  stand-alone  Logistics  Processor  Medical  (LPXMED)  model  was 
provided  to  the  medical  support  staff  of  the  MSF  to  perform  planning,  coordination  and  execution 
fiinctions  associated  with  medical  operations  in  support  of  the  MSF.  The  LPXMED  provided  the 
capability  to  create  detailed  force  structures,  and  to  develop  and  evaluate  medical  support 
requirements,  patient  treatment  and  evacuation  plans,  and  personnel  retum-to-duty  estimates 
based  on  various  operational  scenarios.  This  software  program  ran  on  a  stand-alone  DOS-based 
PC.  Medical  Service  School  personnel  trained  student  users. 

Training  Simulation  Systems 

CBS.  The  Corps  Battle  Simulation  (CBS)  provided  a  basic  map  background  and  a 
computer  force-on-force  simulation  to  drive  the  SIMEXes  and  exercise  Prairie  Warrior.  It 
consisted  of  numerous  user  fimctional  area  terminals  connected  to  a  central  computer  system.  It 
permitted  users  to  execute  maneuver,  fire  support,  army  aviation,  air  defense,  engineer,  logistics, 
and  intelligence  functions  to  simulate  a  division-sized  combat  organization  executing  a 
warfighting  scenario.  CBS  was  joined  with  other  functional  simulations  during  PW  to  form  the 
Confederation  of  Models  (COM)  and  increase  the  scope  and  fidelity  of  the  exercise  environment. 

BICM.  The  Battle  Command  Training  Program  (BCTP)  Intelligence  Collection  Model 
(BICM)  was  a  software  program  that  used  unit  location  databases  and  computer  algorithms  to 
represent  intelligence  sensor  capabilities  to  develop  the  perception  databases  on  opposing  forces 
in  CBS.  BICM  output  was  used  as  input  to  the  AS  AS  Warrior  workstations  to  represent 
intelligence  feeds  to  the  Analysis  and  Control  Element  (ACE)  of  the  MSF  military  intelligence 
(MI)  battalion. 

UAV/JSTARS/HRSS.  The  Unmanned  Aerial  Vehicle/Joint  Surveillance  Target  Attack 
Radar  System/High  Resolution  System  Simulator  (UAV/JSTARS/HRSS)  was  provided  to  the 
aviation,  field  artillery,  and  intelligence  staffs,  and  to  the  maneuver  brigades  of  the  MSF  to 
perform  reconnaisance  and  target  acquisition  functions.  This  system  simulated  the  feeds  from 
UAVs  and  JSTARS  to  provide  realistic  UAV  and  JSTARS  sensor  imagery  to  system  operators  in 
their  respective  staff  sections.  The  software  ran  on  a  networked  array  of  MicroVAX,  SUN 
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SPARC  20,  and  Silicon  Graphics  computers  which  required  a  LAN  and  associated  software  for 
simulation  station  interconnectivity  and  connectivity  to  the  CBS  exercise  driver.  This  system 
required  dedicated  system  operators  who  came  from  the  Battle  Command  Battle  Laboratory  - 
Huachuca  (BCBL  (H))  to  support  the  experiment. 

CSSTSS.  The  combat  service  support/training  support  system  was  a  hardware  and 
software  interface  system  that  took  low  resolution  CBS  combat  results  and  logistics  output,  and 
translated  them  into  detailed  logistics  consumption  data  and  support  requirements.  CSSTSS  then 
fed  the  detailed  information  to  LAD  and  other  logistics  support  information  technologies.  This 
interface  system  was  required  to  make  the  logistics  functional  area  technology  systems  work. 

Connectivity.  The  figure  in  the  box  shows 
the  degree  of  connectivity  that  existed  among  the 
information  technologies.  One-way  feeds  (indicated 
by  single-headed  arrows)  did  not  allow  interaction 
with  the  exercise  driver  (CBS). 


Availability.  The  information  technology 
systems  described  above  comprised  the 
knowledge-based  environment  in  which  the  BCE 
operated.  However,  the  information  technology 
systems  were  not  all  available  throughout  the  entire 
experiment.  The  FAADC2I  system  was  not  available  until  the  second  SIMEX.  The 
UAV/JSTARS/HRSS  was  not  available  until  the  third  SIMEX.  LAD,  although  available  prior, 
was  not  functional  until  PW  when  the  CSSTSS  interface  came  online. 

Observations  and  Findings 
Materiel 

Generally,  the  information  technologies  examined  were  stand-alone,  stove-pipe  systems 
designed  to  support  specific  functional  areas.  Because  most  of  them  had  not  been  previously 
integrated  into  the  Army  Battle  Command  System  (ABCS),  this  integration  was  a  challenge 
during  the  experiment.  The  lack  of  a  totally  seamless  ABCS  environment  was  a  factor  behind 
most  shortcomings  of  the  battle  command  system  as  a  whole. 

Hardware.  The  Army  requires  the  UNIX-based  open  system  achhecture  operating 
environment  as  the  common  operating  environment  (COE)  for  all  Army  tactical  computer 
information  systems.  The  SUN  SPARC  20  is  the  chosen  platform  for  tins  operating  environment. 
This  type  of  hardware  provides  very  powerful  computing  platforms,  but  h  is  »cpensive  relative  to 
PC-based  systems  and  learning  to  operate  in  the  UNIX  environment  was  observed  to  be  difficult 
for  many  of  the  BCE  students. 

Software.  Most  of  the  software  packages  examined  lacked  user  firi«idliness.  Many  of  the 
programs  required  users  to  go  through  multiple,  layered  menus  to  perform  even  the  most  simple 
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of  tasks.  Many  of  the  Phoenix  menu  selection  options  did  not  appear  to  be  intuitive  to  most  of 
the  BCE  users.  Most  of  the  database  queries  demanded  a  user  to  be  familiar  with  structured 
query  language  (SQL),  building  database  queries  with  Boolean  logic  operations  to  successfully 
exploit  the  database  management  system  (DBMS).  As  shown  in  the  table  below,  the  technology 
literacy  self-assessment  indicated  that  the  BCE  would  likely  have  some  problems  with  a  difficult 
DBMS.  There  was  some  improvement  indicated  by  the  re-assessment  (second  row),  which  the 
study  team  also  observed  during  the  experiment. 


TotaUy 

Illiterate 

Some 

Familiarity 

Competent 

Very 

Comfortable 

Totally 

Literate 

Mean  of  1-5 
Scale 

DBMS 

17 

32 

15 

8 

1 

2.23 

11 

26 

13 

5 

2.66 

Solutions  developed  to  software  problems  during  the  experiment  tended  to  be  technically 
oriented  in  their  implementation.  Indeed,  the  Phoenix  system  itself  could  be  characterized  as  a 
very  programmer-oriented  system  at  the  time  of  the  experiment.  Partly  because  of  this  fact,  the 
computer  programmers  on  the  contract  support  staff  usually  had  much  less  difficulty  than  the 
users  did  with  the  software.  However,  this  experiment  reinforced  the  requirement  that  user  (with 
the  user  appropriately  characterized)  friendliness  be  built  in  and  maintained. 

The  software  packages  examined  usually  operated  in  dxvX-Windows  environment  under 
UNIX.  This  is  a  very  powerful  open  architecture  operating  environment  and  is  widely  used  to 
support  scientific  and  complex  business  applications.  This  environment  is  preferred  by  many 
computer  programmers  -  its  power  can  be  very  helpful  in  developing  solutions  to  highly  technical 
problems.  However,  X-Windows  is  fairly  complex,  requiring  a  large  investment  in  education  and 
training  to  gain  and  maintain  users'  proficiency.  When  users  were  thrown  out  of  an  application 
into  X-Windows  or  UNIX  they  were  usually  lost  logically  and  could  not  recover.  An  easier, 
simpler,  and  more  widely  accepted  operating  environment  (such  as  a  DOS-based  Windows 
environment)  should  be  considered  in  part  to  allow  most  users  to  more  readily  recover  fi'om 
failures.  The  technological  literacy  survey  supported  this  view.  As  shown  in  the  table  below  the 
BCE  students  assessed  themselves  as  much  more  competent  with  Windows  and  DOS  than  with 
Unix.  The  first  row  of  the  table  associated  with  each  operating  system  presents  the  results  of  the 
first  survey,  while  the  second  row  presents  the  results  of  the  re-assessment.  The  BCE  seemed  to 
have  some  positive  effect  on  the  students'  UNIX  competency,  but  still  just  over  twenty  percent 
believed  themselves  competent  or  better  at  the  end  of  the  course.  This  is  a  reflection  that  there 
was  not  training  in  UNIX,  per  se,  but  the  familiarization  with  it  from  required  usage  throughout 
the  experiment.  The  results  of  the  re-assessment  regarding  Windows  provide  strong  support  to 
consider  the  use  of  that  type  of  operating  system  or  operating  environment  as  the  COE  base. 
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Networks  and  communications.  Users  experienced  many  problems  related  to  the  network 
and  communications  throughout  the  experiment.  BCE  students  had  difficulty  understanding  the 
network  and  developing  familiarity  with  it.  The  experiment  reinforced  the  need  for  a 
division-level  LANAVAN  manager  and  staff.  The  apparently  complex  network  that  serviced 
Phoenix  proved  to  be  inadequate.  The  network  was  created  by  establishing  one  workstation  in 
each  cell  as  the  server  for  that  group,  which  were  then  linked  together.  The  network  was  not 
specifically  designed,  equipped,  and  managed  to  support  the  MSF  in  the  experiment.  The 
network  was  inadequate  to  handle  the  communications  load  placed  on  it.  The  network  became 
saturated  frequently  and  resulting  data  collisions  interrupted  MSF  communications.  A  VTC 
capability  on  Phoenix  via  the  network  allowed  virtual  collocation  and  collaboration.  However, 
the  network  frequently  ground  to  a  halt  during  the  use  of  VTC.  Use  of  the  VTC  also  locked  up 
the  network  and  prevented  users  from  performing  any  other  functions  on  their  workstations  that 
required  network  access.  Phoenix  also  allowed  an  interactive  graphics  capability  called  a 
whiteboard.  The  whiteboard  allowed  network  users  to  share  graphics  interactively  via  VTC.  This 
particular  capability  facilitated  the  dissemination  of  the  MSF  Commander's  relevant  common 
picture  and  intent  to  the  MSF  command  and  staff.  The  whiteboard  provided  each  networked  user 
a  different  color  light  pen  to  draw  on  the  base  picture.  Because  the  video  portion  of  the  VTC 
consumed  so  much  of  the  network  capacity,  the  MSF  adopted  the  standard  operating  procedure 
of  turning  off  video  and  making  the  conferences  audioteleconferences  (ATCs).  These  ATCs 
relied  on  the  whiteboard  with  a  common  map  background  to  enhance  collaboration.  There  were 
still  periods  when  the  network  could  not  simultaneously  support  the  ATC  with  whiteboard  and 
basic  Phoenix  functions.  During  several  ATCs,  audio  communications  deteriorated  so  badly  that 
conference  participants  reverted  to  using  handheld  radios  for  the  audio  portions  of  the  conference. 

The  network  linkages  between  the  separate  systems  were  also  inadequate.  Large  volumes 
of  data  were  exchanged  between  those  systems  which  were  connected.  Megabyte  sized  database 
transfers  and  file  updates  were  not  unusual.  The  network  usually  slowed  noticeably  when 
supporting  these  operations. 

A  telephone  system  was  available  because  of  the  lack  of  normal  tactical  communications 
systems  in  the  experiment.  It  had  a  conference  call  capability,  but  the  capability  was  little  used  in 
the  conference  call  mode  because  it  limited  participants  to  those  specific  individuals  listening  to 
the  phone  conversation.  There  were  speaker  phones  in  the  cells,  but  the  noise  level  of  the  cells 
made  them  difficult  to  exploit  because  users  could  not  turn  off  voice  transmission  microphones  to 
only  listen.  All  cells'  noise  was  potentially  heard  over  the  conference  line.  Motorola  handheld 
radios  provided  a  capability  to  transmit  immediately  one  to  many  and  served  as  backup  to  the 
audio  portion  of  the  ATC  when  that  broke  up  on  the  computer  network.  These  also  provided  a 
capability  for  many  to  listen  in  on  the  conversation  between  two  participants.  This  proved  a 
valuable  redundant  communication  means  for  the  MSF. 

The  results  of  the  technology  literacy  survey  indicated  the  BCE  experience  raised  the 
competency  of  students  in  the  two  collaborative  technologies,  as  shown  in  the  table  below.  The 
number  of  students  rating  themselves  as  competent  or  better  with  VTC  almost  doubled.  The 
number  of  students  making  an  assessment  of  competency  or  better  in  comms  (representing  PC 
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communications  packages  and  other  communications  (network)  technologies  with  which  the 
students  were  familiar)  increased  over  fifty  percent,  with  over  twenty  percent  of  the  BCE  moving 
into  these  three  top  categories. 
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The  study  team  also  conducted  an  ad  hoc  survey  of  ten  BCE  students  during  PW.  The 
subject  of  the  survey  was  local  area  networks  (LANs),  wide  area  networks  (WANs),  and  the 
Internet.  The  students  were  asked  to  assess  their  knowledge  of  LANs,  WANs,  and  the  Internet, 
their  comfort  with  each,  and  the  frequency  of  their  usage  of  each  of  them.  The  ten  students  all 
had  an  opinion  about  these  technologies  and  believed  they  could  evaluate  them.  On  a  five  point 
scale,  the  mean  response  regarding  knowledge  of  LANs  was  2.9  -  close  to  "medium"  knowledge. 
The  mean  response  for  knowledge  of  WANs  was  much  lower  at  1.7,  falling  between  "none"  and 
"minimal;"  in  fact,  only  one  respondent  indicated  a  knowledge  level  of  WANs  above  "minimal." 
The  mean  response  for  knowledge  of  the  Internet  was  2.6  -  between  "minimal"  and  "medium." 
With  regard  to  comfort,  for  LANs  and  the  Internet,  the  mean  responses  were  2.6  and  2.7, 
respectively,  falling  between  "can  use  with  help  or  presets"  and  "can  use  independently  with 
effort."  Students  were  less  comfortable  with  WANs,  with  a  mean  response  of  1 .6,  between 
"never  done"  and  "can  use  with  help  or  presets."  Eight  of  the  ten  respondents  indicated  their 
frequency  of  internet  usage  was  in  one  of  the  three  lower  categories,  with  a  mean  response  of  2.6, 
between  "only  for  exceptional  reasons"  and  "occasionally."  None  of  the  ten  students  identified 
themselves  as  regular  Internet  users.  The  results  of  this  survey  further  indicate  the  level  of  the 
challenge  to  raise  awareness  and  competency  in  fundamental  knowledge-based  force  technologies. 

Specific  Battle  Command  Systems.  This  section  presents  observations  concerning  the 
individual  battle  command  systems. 

Phoenix.  The  Phoenix  system  was  available  throughout  the  experiment.  Study  team 
members  received  two  hours  of  familiarization  training  and  observed  two  student  groups  each 
receive  sk  hours  of  hands-on  system  training.  The  students  were  observed  for  more  than  150 
hours  operating  the  Phoenix  systems  during  the  three  SIMEXes  and  PW.  The  following 
observations,  related  to  specific  Phoenix  capabilities  are  based  on  this  experience. 

a.  Common  scalable  map  displays.  The  Phoenix  mapping  capability,  although 
good,  lacked  the  robustness  of  a  true  geographic  information  system  (GIS)  for  the 
following  reasons: 

•  lacked  complete  high  resolution  di^tial  terrain  coverage 

♦  lacked  ability  to  scroll  across  terrain 

•  lacked  capability  to  show  data  in  all  map  scales 

♦  lacked  ability  to  perform  the  spectrum  of  terrain  data  processing 
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•  lacked  ability  to  import  and  use  other  than  Defense  Mapping  Agency 
(DMA)  digital  terrain  data 

•  lacked  adequate  screen  display  on  most  workstations  (due  to  size) 

b.  Enemy  and  friendly  force  tracking.  This  capability,  as  demonstrated,  was  based 
on  CBS  feeds.  The  timeliness  of  the  information  updates  was  often  lacking.  These 
were  frequently  one-half  to  more  than  two  hours  old,  because  of  LAN  backlogs  of 
database  updates  during  the  exercises.  Updates  were  not  continuous,  but  at 
designated  time  intervals.  Both  enemy  and  fnendly  unit  database  updates  were 
performed  every  five  minutes  at  the  beginning  of  the  SIMEXes,  but  that  was  later 
changed  to  every  15  minutes  because  the  LAN  could  not  handle  the  data  loading. 
However,  discussions  with  BCE  students  revealed  that  most  of  them  believed  the 
systems  provided  enhanced  situational  awareness  relative  to  current  systems.  This 
may  be  partly  based  on  the  proliferation  of  large  screen  displays  throughout  the 
MSF.  Thirty-seven  inch  monitors  and  a  60  inch  monitor  were  provided  during  the 
experiment  with  Phoenix.  These  displays  enhanced  staff  collaboration,  by 
providing  large  enough  digitally  based  views  of  the  battlespace  that  multiple 
commanders  and  staff  could  view  simultaneously.  Essentially,  it  was  possible  to 
provide  a  somewhat  detailed  view  of  the  MSF's  "big  picture,"  which  in  this  case 
was  an  extended  300  kilometer  long  by  150  kilometer  wide  battlespace.  There 
was  some  apparent  ambivalence  regarding  an  overall  assessment  of  the  system. 

This  ambivalence  is  revealed  in  part  by  the  results  of  the  effects  survey,  shown 
below.  The  specific  survey  question  asked  is  also  shown.  The  first  row  with  each 
respective  system  characteristic  reflects  the  results  of  the  first  effects  survey 
(post-first  SIMEX),  while  the  second  row  shows  the  results  of  the  re-survey 
(post-third  SIMEX).  A  careful  examination  shows  that  speed  improved,  but  that 
neither  timeliness  nor  quality  improved  significantly.  This  indicated  the 
developmental  system  may  have  become  more  efficient,  but  that  it  did  not  become 
more  effective  for  battle  command  in  the  MSF. 

•  Assess  the  effect  of  the  situational  awareness  tools  (e.g.,  integrated  in 
Phoenix  or  ASAS)  on  the  timeliness,  speed,  and  quality  of  situation  assessment 
as  you  observed  it  in  the  exercise. 
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c.  Dynamic  distributive  overlays.  This  capability  permitted  users  to  draw 
operational  graphics  on  the  common  scalable  map  displays  and  transmit  those 
overlays  to  other  user  stations  via  LAN.  Creating  the  overlays  was  cumbersome 
using  the  menu  driven  graphics  package,  taking  up  to  five  separate  menu  selections 
to  draw  a  line.  Once  that  operation  was  complete  it  took  another  five  menu 
selections  to  draw  another  line.  The  method  of  distributing  the  graphics  files  was 
by  e-mail  via  the  LAN.  This  method  was  slow  and  cumbersome  to  use,  the  menu 
selections  were  not  logical,  and  distribution  could  not  be  made  to  groups 
(one-to-many  concept).  E-mail  messages  had  to  be  sent  to  each  individual  work 
station,  contributing  to  network  overloading. 

d.  Voice  activation.  A  voice  recognition  sofl;ware  program  running  on  a  486 
processor-based  personal  computer  was  made  available  to  the  MSF.  It  was 
connected  with  many  of  the  Phoenix  workstations.  This  program  required  users  to 
speak  into  a  headset/microphone  to  calibrate  the  software  to  the  user's  voice 
patterns.  This  process  took  approximately  45  minutes  for  each  user  on  a  machine. 
The  users  could  then  issue  voice  commands  corresponding  to  the  menu  selections 
to  execute  the  Phoenix  operations.  This  system  seemed  to  work  fairly  well,  but  it 
was  not  readily  accepted  by  users.  Users  expressed  concerns  about  the  length  of 
time  required  to  calibrate  the  system,  the  awkwardness  and  rigidity  of  the 
command  structure  (and  menu  selections),  and  the  tethering  of  personnel  to  a 
computer  with  a  hardwired  headset  that  limited  personal  mobility.  The  system  did 
not  work  well  in  PW  because  of  the  higher  levels  of  activity  and  the  increased 
levels  of  background  noise.  The  system  included  the  capability  to  adjust  to  varying 
levels  of  background  noise,  but  students  received  no  training  on  how  to  make 
these  adjustments. 

e.  Interactive  graphics.  This  capability  was  accomplished  through  the  whiteboard 
-  a  software  program.  This  permitted  users  to  join  a  conference  on  the  network  as 
a  VTC,  but  using  only  the  white  board.  The  conference  participants  could 
individually  and  in  turn  bring  graphics  (usually  maps  and  overlays)  into  the 
whiteboard,  where  all  could  then  see  and  share  the  same  picture.  Each  participant 
could  then  use  seperate  mouse-driven  colored  markers  to  draw  on  and  highlight 
entities  on  the  shared  picture.  This  feature  worked  very  well  and  was  exploited 
extensively  for  virtually-collocated  command  and  staff  collaboration. 

f  3D  visualization.  This  feature  permitted  users  to  create  a  3D  view  of  the  terrain 
from  a  reference  point  outward.  These  were  individual  snapshots  and  were  useful 
to  gain  topographic  awareness.  However,  it  was  not  observed  to  provide  the  level 
of  detail  needed  for  tactical  operations  planning.  Also,  the  tool  could  not  be  used 
to  develop  "fly-through"  sequences. 

g.  Course  of  action  (COA)  analysis  tool.  This  feature  never  worked.  A  tool  was 
planned  to  provide  movement  planning;  provide  force  ratio  calculations  for  all 
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engagements;  and  provide  screen  captures  of  each  phase  of  each  COA  to  use  to 
develop  branches.  An  automated  wargaming  capability  is  required  that  will  resolve 
force  engagements  and  allow  screen  and  data  captures  that  will  present  a  history  of 
force  engagements  so  that  they  may  be  quickly  analyzed.  Force  ratio  calculations 
do  not  provide  reliable  battle  outcomes  or  help  to  identify  other  synchronization 
problems. 

h.  OPORD  generation  tool.  This  feature  was  to  generate  a  graphical  operations 
order.  It  was  to  dynamically  link  to  other  system  tools,  executables,  and  voice 
files.  Also,  it  was  to  use  the  CECOM  OPORD  generation  tool  with  some 
enhancements  to  expedite  the  order  generation  process.  However,  this  latter 
feature  never  worked,  nor  was  it  demonstrated.  The  operations  orders  that  were 
generated  by  the  MSF  were  graphical  with  supporting  linked  text  blocks. 

i.  Synchronization  matrix.  This  feature  was  to  link  events  from  the  wargaming 
process  to  execution  tools  such  as  the  decision  support  template,  event  template, 
and  others.  This  feature  never  worked  as  intended.  As  implemented  it  merely 
transferred  the  synchronization  matrix  development  process  fi’om  paper  to 
electronic  media.  It  was  very  complex  and  user  unfiiendly.  It  took  up  to  nine 
menu  selections  to  put  each  label  on  a  matrix  column  or  row.  With  up  to  50  labels 
needed  on  a  matrix,  it  was  quicker  and  easier  to  do  it  by  hand  on  a  preprinted 
form. 

j.  VTC.  The  videoteleconference  capability  permitted  multiple  users  to  join  a 
VTC  with  real-time,  interactive  video  and  audio.  This  capability  was  to  be  used 
for  command  and  staff  collaboration,  but  was  ineffective  because  of  the  inability  of 
the  network  to  handle  the  data  volume.  Most  conferences  were  reduced  to  ATCs. 
Sometimes  the  data  loading  was  even  too  great  for  the  ATCs,  as  data  collisions 
caused  breakups  in  the  voice  transmissions.  The  results  of  the  technology  survey 
are  shown  again  below.  These  indicate  the  effect  of  the  BCE  experience  with 
regard  to  VTC  literacy.  They  show  a  significant  increase  in  student  competency, 
although  just  over  half  assessed  themselves  as  competent  or  higher  at  the  end  of 
the  course. 
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Many  other  general  observations  were  made  during  the  experiment.  User  training  was 
inadequate.  The  system  was  too  complex  to  achieve  competency  during  the  limited  training 
period.  Further,  this  period  did  not  even  permit  adequate  familiarization  with  the  system,  so  as  to 
gain  competency  through  self-development.  There  were  several  factors  contributing  to  the 
training  difficulties.  One  factor  was  the  requisite  reliance  on  the  multi-layered  menu  system.  A 
second  factor  was  the  required  use  of  SQL.  A  third  factor  was  the  lack  of  simple,  familiar  office 
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automation  programs  for  word  processing,  graphics,  database  management,  spreadsheet,  and 
e-mail.  As  shown  by  the  results  of  the  technology  survey  in  the  table  below,  the  BCE  students 
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assessed  themselves  highest  in  word  processing  and  graphics,  which  are  standard  office 
applications  proliferated  throughout  the  Army.  Because  of  this,  programs  of  this  type  in  Phoenix 
would  likely  have  enhanced  the  usefulness  of  the  system.  The  ability  to  associate  text  with 
graphics  was  limited  to  electronic  "post-it  notes,”  which  had  many  technical  problems  and  were 
awkward  to  use.  At  one  point,  over  300,000  post-it  notes  were  attributed  to  one  student.  E-mail 
was  also  overly  problematic  relative  to  the  state  of  the  technology.  As  an  example,  during  the 
experiment  routine,  e-mail  text  messages  inexplicably  reproduced  in  the  system,  hidden  from  and 
unknown  to  users.  At  one  time,  over  3,000  e-mail  messages  were  backed  up  in  one  mail  box. 

This  backlog  was  due  to  the  problem  of  transparent  replication  of  messages.  A  fourth  factor 
contributing  to  the  training  difficulties  was  the  lack  of  standardized  file  names  which  resulted  in 
overwritten  files  and  lost  data,  which  even  occurred  while  programmers  were  using  the  system. 

A  print  capability  was  not  developed  for  Phoenix  until  late  in  the  experiment  because 
BCBL(L)  was  exploring  the  concept  of  a  "paperless  TOC."  Hardcopy  output  was  needed  for 
reference  and  collaboration,  and  as  a  backup  to  electronic  media.  There  was  no  initial  capability 
to  download  or  backup  user  files.  This  and  the  inability  to  print  caused  the  students  to  recreate 
complete  sets  of  plans  and  orders  and  the  associated  graphics  on  at  least  three  separate  occasions 
when  data  were  lost  because  of  system  and  network  problems.  The  idea  of  a  "paperless  TOC" 
was  thus  demonstrated  to  be  on  the  wrong  track.  The  maximization  of  electronics,  as  opposed  to 
the  complete  elimination  of  paper,  was  demonstrated  to  have  merit. 

ASAS  Warrior.  The  ASAS  system  provided  the  basic  required  intelligence  functionality. 
ASAS  ran  on  hardware  common  with  Phoenix  and  was  driven  by  multiple  menu  layers.  This 
system  required  users  to  be  knowledgeable  in  both  SQL  and  UNIX.  The  system  received 
intelligence  sensor  feeds  from  the  CBS  model  via  BICM.  These  data  were  sorted  into  databases 
by  sensor  discipline.  Intelligence  analysts  collated  and  analyzed  the  data  and  developed  an  enemy 
picture.  An  updated  intelligence  picture  was  transmitted  throughout  the  MSF  and  used  to  plan 
and  monitor  operations.  The  transmission  of  the  intelligence  updates  was  accomplished  through 
database  updates  of  the  enemy  situation.  These  updates  were  planned  to  occur  every  five 
minutes,  but  because  of  the  volume  of  data  required  to  be  transmitted  and  the  design  of  the  LAN, 
the  update  interval  was  changed  to  every  fifteen  minutes.  The  data  were  current  in  these  updates, 
to  the  precision  of  the  interval.  This  increased  interval  still  created  problems  during  PW  because 
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of  increased  organizational  activity  and  corresponding  increased  data  usage  on  the  LANs. 
Intelligence  update  backlogs  sometimes  ran  as  high  as  two  hours  and  the  staleness  of  this 
information  adversely  affected  the  staff  throughout  the  experiment.  The  uncertainty  as  to  how 
fresh  near-real-time  information  actually  was  disrupted  the  MSF  staff  on  several  occasions,  but 
the  freshness  problem  was  somewhat  mitigated  by  their  increasing  awareness  of  it.  This  problem 
was  mainly  related  to  the  network  and  configuration  of  systems  in  the  experiment,  as  opposed  to 
the  ABCS  concept.  Information  within  the  ASAS  databases  was  detailed  and  original  data  were 
time-tagged,  but  accessing  this  information  required  a  high  skill  level.  ASAS  Warrior 
workstations  required  the  dedicated  operators  provided  who  were  trained  in  specific  intelligence 
disciplines  and  the  system  hardware  and  software.  User  fifendliness  was  lacking,  but  was 
mitigated  by  the  dedicated  support.  The  results  of  the  surveys  regarding  the  effect  of  the  suite  of 
battle  command  tools  on  the  intelligence  BOS  are  shown  below.  The  intelligence  BOS  results  are 
predominantly  an  indication  of  the  effect  of  ASAS  Warrior,  because  of  the  proliferation  of  the 
information  from  this  system  throughout  the  MSF.  There  was  some  shift  of  respondents  into  the 
positive  categories.  The  BCE  was  generally  pleased  with  enemy  situational  awareness  during  the 
course  of  the  experiment,  primarily  because  they  were  provided  much  more  information  on  both 
enemy  and  friendly  forces  than  systems  they  had  used  provided  to  them. 
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AFATDS.  AFATDS  provided  the  basic  required  fire  support  functionality.  The  map 
background  was  a  piece  of  featureless  terrain.  Although  it  may  be  backed  up  with  digital  data,  the 
general  terrain  picture  was  a  white  or  beige  background  superimposed  with  grid  lines  and  control 
measure  graphics.  The  DBMS  commands  were  either  menu  or  manually  entered.  AFATDS  was 
cumbersome  and  did  not  provide  the  required  data  entry  flexibility.  For  example,  when  a  target 
was  identified  on  the  display  screen,  the  operator  had  to  manually  enter  the  grid  coordinates 
instead  of  clicking  on  that  location  with  a  mouse  and  entering  those  coordinates  into  the  AFATDS 
fire  mission  format.  When  a  fire  mission  was  repeated,  all  targeting  information  must  be  entered 
manually  for  each  data  element  required  on  the  fire  mission  work  menus.  There  was  no  copy  and 
paste  capability.  Thus,  user  fnendliness  was  lacking.  The  results  of  the  effects  surveys  regarding 
the  effect  of  the  suite  of  battle  command  tools  on  the  fire  support  BOS  are  shown  below.  This  is 
presented  to  provide  an  indication  of  the  effect  of  AFATDS  on  the  fire  support  BOS.  There  was 
almost  no  change  of  respondents  regarding  fire  support.  The  responses  related  to  fire  support 
indicated  that  the  BCE  was  generally  pleased  with  support  to  fire  support  during  the  experiment. 
Observations  revealed  nothing  to  the  contrary  to  this  indication  with  regard  to  AFATDS  in  the 
experiment. 
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FAADC2I.  The  FAADC2I  system  provided  basic  air  defense  C2  functionality.  The 
FAADC2I  map  background  was  a  piece  of  featureless  terrain.  Although  it  may  be  backed  up  with 
digital  data,  the  general  terrain  picture  was  a  white  or  black  background  with  grid  lines  and 
control  measure  graphics  superimposed  on  it.  The  DBMS  commands  were  either  menu  or 
manually  entered.  It  was  cumbersome  and  not  designed  for  maximize  efficiency  or  operator 
effectiveness  nor  did  it  provide  the  flexibility  needed  for  multiple  data  entry  methods.  There  was 
no  copy  and  paste  capability.  Again,  in  general,  user  friendliness  was  not  a  strong  point  of  the 
system,  but  it  was  better  than  some  other  systems.  The  results  of  the  effects  surveys  regarding  the 
effect  of  the  suite  of  battle  command  tools  on  the  air  defense  BOS  are  shown  below.  This  is 
presented  to  provide  an  indication  of  the  effect  of  FAADC2I  on  the  air  defense  BOS.  There  was 
some  shift  of  respondents  out  of  the  negative  categories.  The  responses  related  to  air  defense 
indicated  that  the  BCE  became  much  more  pleased  with  support  to  this  BOS  over  the  course  of 
the  experiment.  Observations  revealed  nothing  to  the  contrary  to  this  indication  with  regard  to 
FAADC2I  in  the  experiment. 
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LAD.  LAD  required  the  CSSTSS  interface  with  the  CBS  system  to  generate  the  logistics 
data  for  the  LAD.  The  LAD  was  not  functional  until  PW,  but  was  on  hand  in  the  first  SIMEX. 
This  was  primarily  because  the  CSSTSS  interface  was  not  available  until  PW.  Although  LAD 
permitted  the  detailed  tracking  of  supplies,  it  did  not  provide  any  feature  to  permit  the  users  to 
forecast  logistics  requirements.  Data  mismatches  among  the  CBS,  CSSTSS,  and  LAD  systems 
plagued  LAD  throughout  the  experiment.  The  results  of  the  effects  surveys  regarding  effects  of 
the  suite  of  battle  command  tools  on  the  CSS  BOS  indicate  the  extent  to  which  the  lack  of 
integrated  logistics  tools  affected  the  experiment.  Over  90  and  80  percent  (first  and  second 
survey)  who  rated  the  effects  on  the  BOS  in  the  two  surveys,  rated  the  suite  effects  as  neutral  or 
worse.  These  were  the  worse  ratings  of  any  BOS. 
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TEM/OPS.  The  TEM  portion  of  the  system  provided  a  very  high  quality  digital  mapping 
and  terrain  analysis  capability  to  the  MSF  staff.  It  was  also  capable  of  transmitting  terrain 
information  to  other  systems  (e.g.,  Phoenix).  However,  because  the  system  would  try  to  transfer 
the  entire  digital  data  base  for  the  geographic  area  concerned,  huge  files  (up  to  33  megabytes) 
were  created  to  transfer.  This  transfer  would  completely  degrade  LAN  performance.  The  OPS 
portion  of  the  system  provided  a  good  tool  to  plan  engineer  work  and  to  compare  engineer 
requirements  with  capabilities. 
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NET.  The  NET  provided  a  useful  digital  map  display,  but  it  lacked  the  terrain  analysis 
capability  to  adequately  support  the  evaluation  of  tactical  communications  networks  in  a  timely 
manner.  The  capability  to  assess  communications  network  connectivity,  loading,  and  routing  is 
unknown  because  the  NET  was  a  standalone  system,  and  the  communications  network  used 
during  the  SEMEXes  and  PW  were  commercial  LANs. 

OPLOG  Planner.  This  system  provided  the  only  automated  forecasting  tool  available  to 
the  logistics  elements  of  the  MSF  during  the  SIMEXes.  The  system  was  fairly  user  friendly. 
However,  the  student  users  had  to  develop  their  own  database  to  support  the  operation.  This 
took  most  of  the  users'  time  during  the  first  two  SIMEXes. 

LPXMED.  This  software  program  provided  the  only  medical  services  forecasting 
capability  for  the  MSF  during  PW.  It  performed  as  desired  and  was  fairly  user  fnendly. 

Specific  Training  Simulation  Systems.  This  section  presents  observations  concerning  the 
individual  training  simulation  systems. 

CBS.  The  CBS  system  provided  a  low  resolution  simulation  to  exercise  a  division  level 
staff.  Because  of  the  division  level  training  mission  which  CBS  meets  as  the  Army's  premier  staff 
training  system,  it  was  not  designed  with  the  fidelity  to  fiilly  represent  the  actions  of  all  the  forces 
being  exercised  in  the  SIMEXes  and  PW.  A  drawback  to  using  CBS  for  the  experiment  was  that 
operators  still  had  to  manually  insert  the  actions  that  the  units  executed,  when  that  information 
had  already  been  planned,  coordinated,  and  directed  through  separate  stand-alone  or  networked 
functional  area  information  systems  in  the  digitized  MSF.  As  shown  prior  in  the  connectivity 
diagram,  most  of  the  functional  area  systems  did  not  interface  with  CBS  in  this  experiment. 

CBS  required  contractor  personnel  as  CBS  operators.  Because  these  individuals  were  not 
adequately  familiarized  with  either  the  MSF  or  DBS  concepts,  the  support  to  the  staff  was 
adversely  affected  to  some  extent.  Also  affecting  the  degree  to  which  CBS  supported  the 
evaluation  of  the  MSF  and  DBS  concepts,  was  the  fact  that  CBS  lacked  the  flexibility  to  allow 
multifunctional  workstation  tasking.  Currently  CBS  workstations  are  limited  to  single  functional 
area  capabilities,  appropriately  corresponding  to  the  current  division  structure.  However,  the 
DBS  concept  required  multifunctional  staff,  which  CBS  was  not  designed  to  support.  For 
example,  a  user  at  a  CSS  workstation  could  not  execute  maneuver  or  fire  support  functions  from 
the  same  workstation,  even  though,  as  an  example,  that  user  may  also  have  had  responsibility  for 
command  and  control  of  those  functions  in  the  sanctuary. 

BICM.  The  BICM  met  requirements.  BICM  provided  hundreds  of  sensor  reports  to  the 
ASAS  workstations. 

UAV/JSTARS/HRSS.  This  system  was  not  available  to  the  MSF  until  the  third  SIMEX. 

It  provided  a  realistic  simulated  imagery  input  to  the  intelligence,  aviation,  field  artillery,  and 
maneuver  brigade  staffs.  This  "imagery"  was  based  on  flying  UAVs  over  simulated  CBS  terrain 
to  locate  and  identify  enemy  units.  The  coverage  of  JSTARS  over  this  terrain  was  also  provided. 
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This  system  showed  the  value  of  such  imagery  intelligence  systems  and  contributed  to  the  MSFs 
success  in  deep  operations.  However,  the  system  was  somewhat  complex  and  user  unfriendly, 
and  the  simulated  locations  of  specific  vehicles  and  targets  in  UAV/JSTARS/HRSS  did  not  match 
the  aggregate  modeled  locations  in  CBS. 

CSSTSS.  This  simulation  system  was  not  functional  until  PW.  It  did  provide  an  interface 
between  the  CBS  simulation  and  LAD.  It  took  aggregated  logistics  data  from  CBS  and  generated 
the  detailed  logistical  data  necessary  to  exercise  logistics  within  the  PW  scenario.  However,  there 
were  data  mapping  problems  which  created  inaccurate  data  in  LAD,  causing  loss  of  users' 
confidence.  As  with  most  of  the  other  systems  in  the  experiment,  user  fiiendliness  was  lacking. 

Materiel  development.  Phoenix  was  undergoing  prototype  development  throughout  the 
experiment.  Phoenix  was  continuously  upgraded  as  new  capabilities  were  developed  or  changed 
as  problems  were  fixed.  This  process  was  a  training  challenge  for  the  MSF  Commander  and  the 
BCE  students.  This  process  of  prototyping  created  ripple  effects  through  the  entire  suite  of 
software  without  being  readily  detected.  Because  the  software  was  not  mature,  contractor 
personnel  were  constantly  on  site  and  called  on  to  help  users  recover  from  failures,  to 
troubleshoot  the  system,  or  to  explain  system  changes  to  the  users.  The  users  were  then 
responsible  to  remember  the  current  correct  procedures.  The  original  Phoenix  users  manual  was 
outdated  within  one  month  of  issue  to  the  students  and  it  was  never  updated. 

Organization 

Simply  inserting  technology  into  an  organization  does  not  change  how  an  organization  is 
structured  or  how  it  works.  The  thrust  of  this  experiment  was  to  flatten  the  headquarters  to 
exploit  information  technology  in  a  knowledge-based  force.  There  was  a  conscious  effort  to 
change  the  organization  and  processes  of  the  MSF  command  and  staff,  based  on  these  information 
technologies.  A  detailed  discussion  of  the  impacts  of  materiel  on  staff  organization  and  process  is 
presented  in  the  TRAC  technical  monograph,  "Staff  Organization  and  Processes  for  the  Digitized 
Division. " 


Soldiers 

The  main  soldiers  issue  concerned  the  efficiency  and  effectiveness  of  man/machine 
interfaces.  User  fiiendliness  was  a  problem  for  most  of  the  systems  examined.  The  software 
programs  were  apparently  cumbersome  and  difficult  to  use  for  the  majority  of  the  BCE. 
Regardless  of  the  level  of  difficulty  associated  with  the  use  of  advanced  technology  systems,  the 
technology  surveys  showed  that  competency  in  all  technologies  increased  through  the  BCE. 
Experience  with  these  complex  systems  somewhat  mitigated  the  inherent  problems  associated 
with  using  them. 

The  results  of  the  leader  competency  survey  revealed  two  important  findings  for  the  future 
force.  First,  decisionmaking  skills  in  this  knowledge-based  environment  were  assessed  as  highly 
important  and  difficult  to  acquire.  The  BCE  students  assessed  the  difficulty  of  acquisition  even 
higher  at  the  end  of  the  course  than  at  the  beginning.  Interviews  determined  that  this  increased 
perception  of  the  difficulty  of  acquisiton  of  this  competency  was  based  primarily  on  the  students' 
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realization  of  the  information  overload  that  will  occur  in  this  type  of  environment.  These 
advanced  information  technologies  must  mitigate  this  problem  of  information  overload.  Second, 
the  use  of  available  systems  was  initially  assessed  as  both  highly  important  and  difficult  to  acquire. 
However,  their  perceptions  of  the  difficulty  of  acquisition  declined  over  the  BCE.  This  indicates 
that  the  experience  with  the  systems  in  the  experiment  was  a  mitigating  factor  in  the  difficulties 
users  face  with  new,  advanced  technology  systems.  Two  other  TRAC  technical  monographs 
address  the  topics  discussed  above.  These  are  "Mobile  Strike  Force  -  Literacy  Assessments: 
Implications  for  Force  XXI"  and  "Leader  Competencies:  Implications  for  Force  XXI. " 

Conclusions 

The  battle  command  information  technology  capabilities  collectively  affected  division  staff 
processes  and  organization  in  several  ways.  First,  although  the  technology  suite  provided 
enhanced  situational  awareness  to  the  MSF,  the  lack  of  seamless  connectivity  diminished  the 
potential  of  the  data  available  to  the  MSF,  primarily  with  regard  to  timeliness.  This  lack  of 
connectivity  also  precluded  the  study  team  from  completely  assessing  this  issue.  Second, 
communications  among  the  command  and  staff  were  complicated  by  the  proliferation  and 
limitations  of  information  technology.  VTCs,  ATCs,  phones,  radios,  and  e-mail  provided  many 
communications  means  for  the  MSF  -  but  these  means  were  generally  lacking  in  quantities  or 
maturity  of  features,  and  taken  together  often  confounded,  rather  than  helped  the  BCE.  Third, 
information  overload  adversely  affected  the  MSF  to  a  significant  degree,  demonstrating  the  need 
for  data  filters  throughout  the  system  to  help  to  develop  the  relevant  common  picture.  Finally, 
these  capabilities  were  generally  provided  by  systems  characterized  as  lacking  user  friendliness, 
which  was  frustrating. 

Computer-assisted  wargaming  could  not  be  assessed,  except  that  the  absence  of  such 
automated  support  was  notable  by  most  key  experiment  participants.  No  observation  indicated 
that  the  requirement  for  a  computer-assisted  wargaming  tool  is  not  still  valid. 

The  experiment  results  strongly  implied  that  fully  integrated  command,  control,  and 
intelligence  systems  better  achieve  a  relevant  common  picture  of  the  battlefield  than  "stove-piped" 
systems.  The  suite  of  systems,  far  from  fully  integrated,  provided  enhanced  situational  awareness 
to  the  MSF.  Whenever  there  was  any  degree  of  integration  accomplished,  the  effect  on  battle 
command  was  positive.  The  myriad  of  ABCS  systems  must  be  fully  integrated  to  support  the 
force  commander  with  a  relevant  common  picture.  These  systems  must  be  integrated  to  achieve 
the  requisite  timeliness  implied  by  relevancy. 
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